Federated architecture for electronic payments using a payment bus

ABSTRACT

Described herein is an Internet of payments, i.e., a loosely coupled, federated architecture for electronic payment in which payers and payees interact through an Internet-based store-and-forward payment bus to complete an electronic payment. Merchants may use any payment service or gateway and any device to place a payment request on the payment bus; similarly, payers may use any payment service or gateway from any device to make a payment toward the payment request. Embodiments describe how this invention addresses different types of payments including contactless physical payments, online payments and vending machine and kiosk payments, with scenarios illustrating voluntary donations, paying a restaurant check with tips from a mobile device, automated actions at the completion of a payment (e.g., issuing a ticket by a ticketing kiosk) etc.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuing application of U.S. patentapplication Ser. No. 17/129,141 titled “System and Method forPayer-centric Electronic Payments” which claims the benefit of U.S.provisional patent application U.S. 62/950,361 with the same title. Theforegoing applications are hereby incorporated by reference in theirentirety.

FIELD OF INVENTION

This invention is in the fields of electronic payments. It describessystems and methods that enable payers to pay from their own computingdevices for online and offline payments.

BACKGROUND

Today's electronic payments fall into two main paradigms:merchant-centric and walled-garden. In the merchant-centric paradigm(MCP), the payee or the merchant initiates, owns, and orchestrates thepayment process: when the payer checks out, the merchant creates atransaction record in a cash register or database, obtains the payer'spayment credentials, and sends the payment amount and the credentials toa payment gateway such as Payment Tech or Stripe. The gateway obtainspayment authorization from the financial institution that controls thecustomer's payment source and returns a confirmation code to themerchant. The merchant updates his or her transaction record andprovides the customer a receipt. As such, in MCP, merchants or payeesinitiate, own, and orchestrate the entire payment process. FIG. 01provides a high-level view of the MCP paradigm. Please note thatcontactless mobile payments are no exception to the MCP paradigm.Instead of presenting a payment source or credit card physically to amerchant, contactless payment technologies simply transmit the paymentcredentials wirelessly to the merchant. It is the merchant, not themobile device, that orchestrates the payment process.

The MCP paradigm presents several problems and disadvantages for bothcustomers and merchants. A well-recognized disadvantage is that, in theMCP paradigm, customers have to share their credentials with eachmerchant to whom they make a payment. An unscrupulous store clerk or awaiter can easily appropriate and abuse a customer's payment credential.More seriously, the IT systems that store the payment information can bebroken into by cyber criminals from anywhere, leading to wholesale theftof thousands of payment credentials at once—an occurrence that's all toocommon.

MCP poses several problems for merchants as well.

-   -   Payment infrastructure such as card readers, PIN entry pads,        contactless NFC readers etc. involves significant capital and        ongoing operating costs for merchants.    -   Failure of the infrastructure is catastrophic for a merchant due        to lost sales and revenue.    -   For physical payments, the MCP paradigm requires contact and/or        proximity between the payer and the payee. With credit cards,        the payer has to physically swipe a card into the payee's card        reader. With contactless, the payer's mobile device must be        within a few inches from the merchant—a constraint that is        inconvenient for drive-in payments.    -   In eCommerce, the MCP paradigm often acts as a barrier to entry        for small merchants since customers are reluctant to provide        their payment credentials to small merchants, and/or resistant        to re-entering their payment credential into yet another        website.    -   For automated vending machines that are unattended and exposed        to the elements, a full-fledged payment machinery with card        readers and wide-area data connection can be expensive as they        have to be rugged and tamper-proof.

Payment systems like PayPal and Alipay exemplify the walled gardenparadigm (WGP). While WGP payment systems do not require the customer toshare one's payment credential with the merchant, they require that bothpayers and payees—whose credentials or funds they hold in escrow—betheir clients inside a “walled garden.” When a payer approves a payment,WGP systems release an escrowed card to themselves and complete thepayment as a payment gateway. As such, they create a closed ecosystemwithin which both merchants and customers have to operate. While someWGP systems enjoy considerable market success, their walled gardenapproach means that, if a particular merchant is not within the samewalled garden as the payer, the payer is forced to reveal one's paymentcredential to that merchant, creating a weak link as before. As weaklinks proliferate, the risk that the payer's credentials would becompromised through one weak link or another goes up. Put differently,the apparent safety afforded by WGP systems such as PayPal or Alipaydoes not stem from technical merits, but from market dominance or thesize of their walled garden. WGP also leads to the lock-in of bothpayers and merchants as well as lack of competition, consumer choice andinnovation.

This invention describes a payment system that is neithermerchant-centric nor a walled garden. It provides a true Internet ofpayments: an address space in which payers, payees and payment recordsare uniquely identified; a synchronous and on-demand payment bus; and afederated payment model that enables merchants to use any paymentservice or gateway and any device to request payment from a payer, andpayers to use any payment service or gateway from any device to fulfillthe request. Embodiments describe how this invention addresses differenttypes of payments including contactless physical payments, onlinepayments and vending machine and kiosk payments, with scenariosillustrating voluntary donations, paying a restaurant check with tipsfrom a mobile device, automated actions at the completion of a payment(e.g., issuing a ticket by a ticketing kiosk) etc.

SUMMARY

FIG. 02 is a high-level overview of our invention. Merchants placepayment requests on an Internet-based payment bus that operates withinan address space in which merchants, payers and payment records are alluniquely identified. The payment bus ferries the requests to the payers;alternatively, payers retrieve the payment request on demand from thepayment bus. Payers pay for these requests in any way they please, fromany device, at any time, through any payment gateway; then they place aconfirmation of their payment transaction onto the same bus to beferried back to the merchant. Since customers pay from their owndevices, customers do not depend on the merchant to complete thepayment. We refer to embodiments of our invention as Payer-CentricPayment Systems (PCPS).

Functionally, embodiments of this invention enable customers to have asingle payment system on their own devices from which they can pay anyparticipating merchant—a physical store, a website, or a vendingmachine—without sharing their payment credentials with the merchant.Embodiments of this invention enable customers to pay anonymously or viaan alias and enable merchants to accept payments without any paymentinfrastructure.

Structurally, the heart of a PCPS embodiment is a payment bus that actsas a store-and forward conduit through which payers and payees exchangepayment-related messages within a uniform name or address space. Whatthis means is that (a) payers, payees and payment-related messages haveunique identities through which they can be referenced and retrieved,and (b) payment requests from merchants are no longer internal,transient records inside a merchant's cash register or IT system, butare externalized and placed into the payment bus as first-class objects,(c) the bus can deliver a payment message synchronously and withoutpolling to a designated recipient, and (d) the bus can also delivermessages on demand in case of system failure or if the recipient is notknown when a payment request is made (embodiments E2 and E4). As such,payment requests can be accessed from anywhere on any device via theInternet. As a result, a payment request can originate in one place—say,at a cash register or an online shopping cart—and can be paid from adifferent device and at a different time by the customer.

We now delve one level deeper to introduce payer agents and merchantagents. The agents act on behalf of (and as proxy for) payers andmerchants. They handle the mechanics of integration with the payment busand payment gateways, the tedium of bookkeeping, authentication, andother low-level functions. FIG. 06 depicts a scenario from oneembodiment: when a payer checks out at a store, the merchant sends apayment request to the merchant agent and displays the request's ID as aQR code. The merchant agent places the request in the payment bus. Whenthe payer scans the code with her mobile, the payer's agent retrievesthe request by ID from the bus and displays it in the payer's device.The payer can enter a payment credential. The payer agent contacts apayment gateway to complete the payment and places a payment transactionrecord confirming the payment in the payment bus. The bus ferries it tothe merchant agent who verifies the transaction and credits themerchant.

The payment bus differs from today's payment systems in many importantways. First, the bus nature of the payment bus enables all the partiesto synchronously receive data that concerns them. Second, the addressspace of the bus makes customers, merchants, and transactions uniquelyaddressable across the Internet by anybody with right accesscredentials. Third, the externalization of the payment request throughthe bus eliminates the tenuous nature of the transient associationbetween a transaction record and a customer. This means that atransaction can originate at one device in one organization and can beaccessed from another device elsewhere immediately or at any later timethrough its unique ID.

Since the transaction is no longer owned by or hidden inside amerchant's cash register or IT system, it is no longer confined to bepaid only through that merchant. It can be paid directly by the payerthrough any payment gateway or through any agent of the payer's choice.As a result, this invention provides a paradigm that is neithermerchant-centric nor does it create a walled garden. Instead, thepayment bus provides a federated architecture that accommodates anynumber of payment gateways, payer agents and merchant agents to coexistand cooperate.

LIST OF FIGURES

FIG. 01 provides a high-level pictorial view of the Merchant-CentricPayment paradigm.

FIG. 02 provides a high-level overview of this invention.

FIG. 03 is a schematic that shows the structure of our invention and itsmajor components.

FIG. 04 depicts different technical architectures for Payer Agent asused in some embodiments.

FIG. 05 is a schematic of the Payer Identity Manager PIM.

FIG. 06 provides a summary of the of the payment method described inthis invention.

FIG. 07 depicts different architectures for Payment Presenter used insome embodiments

FIG. 08 depicts different technical architectures for Merchant Agent.

FIG. 09 is a schematic of the Merchant Identity Manager MIM.

FIG. 10 is a screenshot of the Merchant Profile Manager MPM from anembodiment.

FIG. 12 depicts a Payment Bus implementation using webhooks.

FIG. 13 depicts many payer and merchant agents in a single addressspace.

FIG. 14 is a screenshot of a merchant creating a payment request and itsJSON representation.

FIG. 15 is a screenshot from E0 of a payment request and its paymenttransaction record PTR.

FIG. 16A depicts the steps that subsystems of E0 go through to execute apayment process.

FIG. 16B depicts the dataflow of embodiment E0 as it executes the stepsof a payment.

FIG. 16C depicts the dataflow of E0 from the point of view of MA 302, PA300 and PB 312.

FIG. 17 contains screenshots of the payment screen from E1.

FIG. 18 shows different scenarios for an infrastructure-less cashregister.

FIG. 19 shows the process flow for the infrastructure-less cashregister.

FIG. 20 shows a restaurant creating a payment request for a customer andthe printed check.

FIG. 21 shows the payment and payment acknowledgment screens from E2.

FIG. 22 shows the shopping cart from E3.

FIG. 23 shows the JSON representation of payment request for E3 and E4.

FIG. 24 shows the shopping cart from E4.

FIG. 25 is a schematic of PayPal payment model for comparison with ourinvention.

FIG. 26 shows the claim screen and the payment screen of payment app ofembodiment E4.

FIG. 27 shows a regular and a modified vending machine that can acceptpayment from E4.

FIG. 30 shows a bus company using a poster as a ticket vending kiosk(scenario for E5).

FIG. 31 shows the JSON for a payment request and the payment screen fora ticket.

FIG. 32 depicts the delivered tickets and the app for theirverification.

FIG. 33 depicts the process flow in E5.

DETAILED DESCRIPTION Structure of the Invention

Our invention, embodiments of which we refer to as a Payer-centricPayment Systems or PCPS, comprises the following subsystems as depictedin FIG. 03:

1. one or more Payer Agents PA 300, where a given PA 300 acts as anagent for one or more payers and manages all aspects of a payer'sinteraction with the PCPS,

2. one or more Merchant Agents MA 302, where a given MA 302 acts as anagent for one or more merchants and manages all aspects of a merchant'sinteraction with the PCPS,

3. a Payment Bus PB 312 that acts as a store-and-forward conduit andenables parties connected to the PCPS to exchange payment-relatedmessages with each other,

4. a Payment Repository PR 314 that acts as the storage cache of the PB312 and stores active payment requests, resolved payment requests, andpayment transaction records. Some embodiments store the pending andresolved payments in physically separate databases, Pending PaymentRepository and Resolved Payment Repository, while others may store themas different tables in the same database,

5. a logical Payer Directory PD 316 is simply a directory of theidentities of all payers recognized by a PCPS embodiment. In someembodiments it may be physical and explicit, whereas in others, it maybe implicit and defined by routing tables and payer identitiesmaintained inside payer agents, and

6. a logical Merchant Directory MD 318 is simply a directory of theidentities of all merchants recognized by a PCPS embodiment. Much likethe payer directory, a merchant directory may be explicit or implicitand we will discuss them both when we discuss the address space of aPCPS.

Payer Agent

A payer registers with a PCPS through a Payer Agent PA 300 of his or herchoice and the agent is responsible for providing all capabilities thatenable that payer to conduct payments through the PCPS. Thesecapabilities include, but are not limited to, registering, andauthenticating the payer, presenting payment requests directed to thatpayer, managing, and monitoring that payer's payment sources (such ascredit cards, bank accounts etc.), completing payments for that payer,and depositing that payer's payment transactions into PB 312.

In one embodiment, the PA 300 comprises a web server and severaldifferent types of clients (see FIG. 04). A PA server serves a browserclient 402, a mobile client or app 404, an API endpoint for programmaticaccess 406, and also a mailer 408 to email (or SMS) a link to a webpagethat displays a payment request. As an example, assume that a customer,angela@elfpoint.com, has just shopped at Franks Store. To charge her,the store would place a payment request addressed to her in the paymentbus. Her PA 300 can deliver the payment request to her through a browserclient 402 on a PC, through an app 404 on her mobile device, or candeliver it as JSON through an API endpoint 406 (to, say, her spreadsheetor accounting software). Based on Angela's preferences, it can also usethe mailer 408 to send her an email with a link to a webpage thatdisplays the payment request.

The Payer Identity Manager PIM 322, a subcomponent of PA 300, isresponsible for managing the identity of the payers registered with thatPA. Besides well-known processes of registration, login and multi-factorauthentication, a given PIM may also provide auxiliary identities (e.g.,phone number) and aliases for its customers. In one embodiment, a PIM322 uses passwords and session cookies to authenticate session-basedaccess, and OpenID Connect with OAuth 2.0 for registering API clientsfor programmatic access with API tokens. Payer accounts may have roleswith specific access privileges. For example, payers can authorize theirauditors and tax preparation software to access a part of their data.The PIM is responsible for managing payer accounts and roles, andimposing authorization rules when anyone accesses PA 300.

FIG. 05 is a schematic of a PIM 322 from one of the PCPS embodiments.All accesses to the PA 300—whether through a user interface or throughAPIs—go through the PIM which checks the access credentials against adatabase of Payer Accounts 508 and a database of Access Policies 510. Ifimproper or no credentials are presented, the user is directed to theSignup Manager 504 or Login Manager 506 or presented with an appropriateerror message.

The Payer Profile Manager PPM 324 is responsible for collecting andmanaging the customer's profile. The customer profile includes basicinformation about the customer including but not limited to name, phonenumbers, aliases, shipping addresses, payment sources such as cards andbank accounts, as well of customer preferences including, but notlimited to, where to deliver what types of payment requests, what typesof payment alerts to provide, when to inform or warn of impendingpayments and so forth.

The Payment Presenter PP 326 is responsible for formatting andpresenting a payment to a payer. Unlike the MCP paradigm where amerchant may implement a specific payment interface, the PCP paradigmmust cater to many different types of merchants. For example, arestaurant may want the payment request to include a field for itscustomers to add tips; an eCommerce vendor may need the payment requestto prompt customers for a shipping address; or a store may want thepayment request to include a field where the customer can providefeedback about their shopping experience. To cater to all these cases,PP 326 depends on both the merchant profile (discussed below) as well asthe payer's profile. For example, a payer's profile may direct that allpayments be presented in Canadian dollars; a merchant profile may directthat all payment requests include an extra field for payers to add a tipto the payment.

FIG. 07 is a schematic showing some architectures for PP 326 to obtaindirectives from a merchant or merchant Agent in presenting its paymentrequests to payers. The approaches shown are illustrative, notexhaustive. The simplest approach is 700 where the payment requestitself includes merchant directives in its body. 704 depicts a flexiblebut more complex approach where the request includes an API-endpointthat PP 326 can call in order to render parts of the payment screen. 702is another approach where PP 326 retains control but takes directions inreal-time from the MA 302. Embodiments provide examples.

Payment Bridge PB 328 is an abstraction layer between PCPS andthird-party Payment Gateways PG 310, so that a PCPS is loosely coupledto the internal details of payment gateways. In some embodiments, the PB328 is implemented as a set of drivers for a range of payment gatewayssuch as Stripe, PayPal, Payment Tech etc.

Merchant Agent

A merchant registers with a PCPS embodiment through a Merchant Agent MA302 and the agent is responsible for providing all capabilities thatenable that merchant to accept payer-centric payments through the PCPS.Such capabilities include but are not limited to authenticating themerchant, placing the merchant's payment requests into the Payment BusPB 312, providing the merchant with information about active andresolved payment requests, and managing the merchant's account with thePCPS. In some embodiments, the MA 302 provides sophisticated dataanalysis tools such as charts, reports, seasonal sales analysis,predictions and so forth. An embodiment may also provide tools to exportdata to third-party packages.

In one embodiment, the MA 302 comprises a web server and several typesof clients as depicted in FIG. 08. The MA server serves a browser client802, a mobile client or app 804 and an API endpoint 806 that acceptspayment requests programmatically from merchants. The web client 802 andmobile client 804 enable small merchants to manually create paymentrequests such as the ones in 1402 (FIG. 14) and 2002 (FIG. 20). The APIendpoint 806 enables larger and eCommerce merchants to create paymentrequests such as the ones in FIG. 23 and FIG. 28.

The Merchant Identity Manager MIM 332 is responsible for managing theidentity and login credentials of a merchant. A merchant may ownmultiple accounts with different roles and privileges. For example, asmall merchant may have a simple username and password with allprivileges, whereas a chain store with several outlets as well as awebsite may have accounts with many roles such as store manager, branchmanager, checkout clerk, website manager etc., who may not only havepasswords for login and session-level authentication, but also APItokens for programmatic access. The MIM 332 is responsible for creatingand managing merchant accounts and imposing authentication andauthorization rules across all merchant access to a PCPS. In oneembodiment, MIM 332 uses OpenID Connect with OAuth 2.0 for managingmerchant accounts and distributing API access tokens.

FIG. 09 is a schematic of a MIM 332 from one of the PCPS embodiments.All accesses to the MA 302—whether through a user interface or throughAPI—go through the MIM 332 which checks the access credentials against adatabase of Merchant Accounts 908 and a database of Access Policies 910.If improper or no credentials are presented, the merchant is directed tothe Signup Manager 904 or Login Manager 906 or presented with anappropriate error message.

As mentioned earlier during our discussion on Payment Presenter PP 326,unlike the MCP payments where the merchant controls how the payment ispresented to the payer, with our invention, the merchant depends on PP326 for how the payment request is presented to the payer. For this, thePP 326 depends on both the payer's preferences (managed by Payer ProfileManager PPM 324) and the merchant's profile, managed by the MerchantProfile Manager 334. The Merchant Profile Manager MPM 334 is responsiblefor collecting the merchant profile information. It uses aquestion-answer paradigm to help the merchant specify the customizationsthat the merchant needs in how the PCPS embodiment manages the paymentprocess for that merchant. Further, the merchant profile may alsoprovide input to the Payment Presenter PP 326 on how to display paymentrequests from that merchant. FIG. 10 is a screenshot of a merchantprofile from an embodiment called Elfpoint which we will revisit later.

The Payment Bus

The Payment Bus PB 312 serves four functions that are critical for arobust and scalable payer-centric payment system. First, it acts as adata conduit across different parties within a well-defined name oraddress space so that payers, merchants, and payment messages all haveunique identities with which they can be referenced and retrieved. Assuch, it creates a loosely-coupled, fully federated payment system:merchants—operating through different merchant agents, possiblycontrolled by different organizations—can request payment and obtainpayment confirmation from payers—operating through different payeragents, possibly controlled by different organizations. A merchant orpayer can switch agents—and new agents can join a PCPSembodiment—without affecting the payment flow.

Second, the payment bus externalizes a payment request as a persistentobject in Payment Repository PR 314, so the payment request is no longerdependent on the merchant's cash register or website for itsfulfillment. The request can be accessed and paid from anywhere.

Third, PB 312 acts as an event and data bus that delivers paymentmessages to concerned parties as and when the messages arrive. Thishelps maintain a synchronous payment flow across the PCPS, without theagents polling a central repository or maintaining point-to-pointcontact.

Fourth, PB 312 is a store-and-forward pipe that delivers paymentmessages on demand. Hence it is tolerant of system and network failures;further, externalization with persistence means that a payment requestcan be created by a PA and (later) “claimed” by a payer. Contrast thiswith today's Internet payments where a network failure can result in thefailure of a transaction or can result in duplicate transactions. We areall familiar with messages such as “this action may make take a longtime. Please do not close the browser or press the browser's backbutton” when we click the “pay” button for an eCommerce transaction.

As such, the payment bus provides an open infrastructure for an“internet of payments” as opposed to walled-garden payment systems oftoday. The payment bus provides a loosely coupled federated architecturefor merchants to request payment from payers and payers to fulfill thesepayment requests. We have kept the payment bus intentionally simple soit can be a very general: it acts as a synchronous store-and-forward andas an (asynchronous) on-demand retrieval mechanism for payment messages.It is stateless, so agents have to manage state through their paymentrecords.

Payment Messages

PB 312 stores and transmits discrete pieces of information that areinterchangeably called payment messages or payment records. One PCPSembodiment implements two types of records: Payment Requests PR andPayment Transaction Records PTR. While these records are structuredobjects within PA 300 and MA 302, they may be serialized with respect toPB 312. We note that serialization refers to the conversion of astructured object into a standards-based representation so that it canbe transmitted from one system to another. In some embodiments, paymentrecords are serialized into JSON (JavaScript Object Notation, anestablished standard), though other embodiments may serialize them toother standards. PRs are used by merchants to request a payment, andPTRs are used by payers or payer agents to confirm a payment.

PRs and PTRs are important but not exhaustive of the kinds ofinformation that need to flow through a payment bus to supportpayment-centric payments. With our embodiments we show how a number ofscenarios can be supported with just these two. Other embodiments mayuse additional types of records to handle scenarios such as refunds,deposits, credit holds etc. We expect a wide range of payment recordtypes to emerge as new types of financial instruments are introduced bybanks, credit card companies and other players in the financial servicesindustry.

Payment Requests or PRs have a header and a body. The fields and valuesin the header are unrestricted though many embodiments of this inventionrecognize the following fields and their associated semantics: type,request ID, merchant ID, customer ID, requested amount, currency unit,expiration date, transaction ID, status, add tips, taxes, informationrequest, tax deductibility and fulfillment count. The body is meant forthe merchant or merchant agent to provide information to the payer orpayer agent and is not processed by PB 312.

As an example, let's consider a payment request PR 1404 (FIG. 14) inJSON representation from a PCPS embodiment. It has the followingsemantics: this is a payment request from the merchant whose identity isFrank's Store to customer angela@elfpoint.com for an amount of 29.95USD, the request is currently active. The payment can be fulfilled whenpaid once, it is not tax deductible and does not expect a tip. The bodyof the payment request can contain additional information (e.g., a billof sale) for the payer.

When a payment request PR is paid by the payer, PA 300 creates a PaymentTransaction Record PTR, adds the PR's ID to the PTR and sends both thePR and the PTR to the payment bus PB 312. The purpose of the PTRincludes but not limited to (a) providing the Merchant Agent MA 302 aconfirmation of the payment, (b) enabling the Payer Agent PA 300 keeptrack of the details of the transaction, and (c) exchanging anyinformation with the merchant (e.g., a shipping address). In oneembodiment, a PTR has three main parts—a header, a tracker, and a body.The header is not encrypted, the tracker is typically encrypted so thatit is only intelligible to the Payer Agent PA 300, and the body is forinformation exchange between the payer and the merchant and could beencrypted. 1504 (FIG. 15) shows a PTR. The header says that it is atransaction record confirming the payment for a specific payment requestwith an ID of 1127745653 from a merchant called Franks Store to acustomer called angela@elfpoint.com for a payment amount of 29.95 USDincurring a transaction commission of 1.21 USD. Further, the transactionis confirmed by the PCPS embodiment with a confirmation number and atimestamp.

When Merchant Agent MA 302 for Franks Store sees this PTR, it wouldconsider the payment request with the ID 1127745653 paid and creditFranks Store's account for the payment. It is worth noting that neitherFranks Store nor its Merchant Agent has any knowledge of the paymentsource (credit card, bank account or whatever) that was used by thepayer as that information is not in the header but in the tracker fieldthat is encrypted for and by the PA 300.

The body of the PTR in 1504 (FIG. 15) is empty, but its tracker tracksor contains information about how the payment request was paid and isintelligible only to the Payer Agent PA 300 because it is encrypted. Itmay be created by the PA 300 itself or by the Payment Bridge PB 328. Itspecifies that the name of payment gateway PG 310 that was used forcompleting the payment, the confirmation code provided by the paymentgateway, the internal token for the payment source used, and thenickname by which the payment source is known to the payer.

A payment request that does not have the status of “active” isconsidered “resolved.” Either it has been paid, declined, canceled bythe merchant, expired, abandoned, or has some other status. In someembodiments (e.g., E1 and E5), the “fulfillment count” parameter maycontrol when a payment request is considered resolved. In someembodiments, the payment repository PR 314 comprises two logicallyand/or physically separate repositories called Active Payment Repositoryand Resolved Payment Repository for more efficient processing. Inothers, they may be simply different tables in the same physicalrepository.

Implementing the Payment Bus

In a simple embodiment with just one PA 300 and just one MA 302 residingon the same server, the PB 312 can be implemented as a relationaldatabase for the payment messages and an event bus that broadcastsdatabase events. PA 300 and MA 302 can subscribe to the event bus aslisteners and be notified of database events and respond only to eventsthat concern them. While not very scalable or secure, this may beadequate for a simple PCPS.

For an embodiment that has several PAs 300 and MAs 302 spanning hundredsof servers across the Internet, PB 312 can be implemented as adistributed, NOSQL database for resolved payment messages, and anin-memory database cache for pending payment requests, and webhooks tosend specific PAs or MAs of fine-grained events and data. FIG. 12depicts a payment bus using webhooks. In this embodiment, the PB 312comprises an Internet server 1200 that has an in-memory database 1202for pending payment requests, and a distributed NOSQL database 1204 forresolved payment requests and payment transaction records. MerchantAgents and Payer Agents register specific webhooks—i.e., URLs thataccept HTTP POST messages—for events that concern them. On the arrivalof a payment message, server 1200 first stores the message, looks upwhat event the message triggers, and then sends a HTTP POST to thewebhook registered for that event in the Webhook Directory 1206. Whilewe have described two solutions, many other technologies can support anInternet-wide payment bus PB 312. REST hooks, Websockets, Pub-Sub,Server Sent etc. are some possibilities.

Address Space

An address space or namespace defines the context within which theidentity of some entity is defined and where the entity is uniquelyaddressable. For example, a filesystem in a computer is an address spacethat uniquely qualifies each file within a hierarchical directorystructure; the Domain Name Service (DNS) of the Internet defines ahighly distributed and hierarchical address space, in which any domain,subdomain or a webpage is uniquely addressable. For smooth payment flowin a PCPS embodiment, it is necessary that a PCPS provide an addressspace in which payers and merchants can clearly identify each other bytheir public identities. In simple embodiments, the address space may benothing more than a flat, PCPS-wide directory of payers and merchants,ensuring that their IDs are unique at the time of registration. If theembodiment has only one Payer Agent PA 300 and only one Merchant AgentMA 302, their respective identity managers PIM 322 and MIM 332 wouldalso be the logical Payer Directory 316 and the logical MerchantDirectory 318 respectively. If there are multiple payer agents andmerchant agents, then the union of their respective PIMs and MIMs wouldconstitute the logical payer and merchant directories with an additionalcheck at the time of registration to ensure that payers or merchants donot have duplicate registrations across agents.

A hierarchically organized address space is more common and scalable. Inthe address space shown in FIG. 13, merchant agents and payer agents aretrusted entities, and their identities are simply their IP addressesmaintained by the payment bus in a routing table. The merchants areidentified by domain names, which are by definition unique. A payer isassigned an email ID at registration where the email ID is part of thedomain of the payer agent that registers the payer and is thereforeunique. In this case, the naming convention used by domain names andemail IDs constitute implicit merchant and payer directories PD 316 andMD 318.

Although a simple embodiment could just inform all agents whenever a newpayment message arrives at PB 312 and let an agent determine if themessage concerns that agent, that would be neither secure not efficient.Most embodiments maintain an association list specifying which payer ormerchant is associated with which agent, though in an address space suchas the hierarchical one shown in FIG. 13, no such list is necessary forpayers since the structure of an email ID automatically specifies itsagent association. Note that, strictly speaking, such association listsare a matter of efficiency and not an integral part of an address spaceper se.

In our invention, it is not just the payers and merchants who areuniquely identifiable, but also payment messages that they send to eachother. Since all payment messages pass through the Payment Bus 312, insome embodiments, it is most efficient to assign an ID to paymentmessages when they are first reach the Payment Bus 312. In otherembodiments, each merchant agent and payer agent may assign an ID thatis unique within that agent's address space, and prefix it with thatagent's own ID, so that the message's ID is unique across the PCPS.

Why have many PAs and MAs? Our invention aims to provide an open andfederated infrastructure for payments and does not subsume anyparticular business model. We imagine that different agents will caterto different market niches, geographies or different class of payers andmachines. For example, one merchant agent could cater to merchants of acertain type while another may cater to only payers in a certaingeography. Similarly, one PA may cater to payers paying with prepaidcredit, another to payers paying with PayPal, and another may specializein discounts and coupons. This invention is agnostic about theunderlying business model.

Embodiments of the Invention Embodiment E0 A Prototypical PaymentScenario at a Store

Assume that embodiment E0 is offered as a service at the fictitiousdomain e0.com. Assume that a payer, Angela, has signed up with e0.com,through one of E0's payer agents called elfpoint.com and is assigned anemail ID angela@elfpoint.com. Assume that she has added two cards as herpayment credentials to her profile. Let us also assume that a merchant,a small convenience store called Franks Store, has signed up with e0.comthrough one of its merchant agents MA 302. The Merchant Profile ManagerMPM 334 will obtain the merchant's name, logo, bank account, and otherinformation through a dialog similar to the one in FIG. 10.

Assume that Angela is at Franks Store's cash register to check out. Themerchant logs into e0.com via a browser, uses the MA 302's browserinterface 802 to create a payment request 1402 as shown in FIG. 14. 1404is the JSON representation of the payment request. In other embodiments,the customer ID may be scanned from the customer's mobile device as abarcode or entered by the customer through a keypad device.

MA 302 now places the payment request PR in the E0's Payment Bus PB 312,which delivers it to Angela's payer agent PA 300. PA 300 consultsAngela's profile and finds that her delivery preference is her mobileapp, so the PR is delivered to her mobile app 404. The Payment PresenterPP 326 presents a payment request based on both merchant's and payer'srespective profiles. PP 326 consults Payer Profile Manager PPM 324 toobtain the two cards stored by Angela in her profile; it also consultsthe Merchant Profile Manager MPM 334 to get Franks Store's logo. 1502(FIG. 15) is the screenshot of the PR as presented to Angela.

To fulfill the payment request PR, Angela can choose a card from herprofile or enter a new card. Her payment source and authorization aredelivered by Angela's app 404 to PA 300. PA 300 sends the merchant IDand the payment source to a Payment Gateway 310 through its PaymentBridge PB 328. If the payment is successfully completed, PG 310 returnsa payment confirmation and PA 300 creates a Payment Transaction RecordPTR with a reference to the payment request ID and merchant ID, thetransaction amount, and the confirmation code provided by PG 310. 1504in FIG. 15 shows the PTR. PA 300 deposits the PTR in the Payment Bus PB312 which PB 312 routes to Merchant Agent MA 302. Now MA 302 verifiesthat the payment amount in the PTR matches the amount billed in the PRand that PTR has a confirmation code. Satisfied, MA 302 changes thestatus of PR as from “active” to “paid.”

FIG. 16A depicts the steps that E0 goes through in the above scenario.FIG. 16B provides an alternate depiction in terms of process flow: MA302, PB 312 and PA 300 are shown left to right and the sequence of theprocess steps from top to bottom. FIG. 16C provides yet another view ofthe process and data flow as seen by MA 302, PB 312, and PA 300. Eacharrow represents the direction of data flow or an action, and the stepsare numbered. “APR⇒RPR” stands for the modification of the status fieldof a payment record from “active” to “paid.”

Embodiment E1 Tipping a Street Performer

Imagine tipping a street performer, a waiter in a food kiosk, or makinga charitable donation to a roadside volunteer. In such scenarios, thereis no formal payment request, and the payee and the payer typically donot know each other's identity. Assume that embodiment E1 is offered asa service at the fictitious domain e1.com. Payees register with e1.comas merchants and are provided a URL and a corresponding QR code thatidentifies them. A payee is free to display the QR code in any location.For such payees, E1 creates a persistent payment request which has thepayee's identity, but no payment amount.

When a payer—who may or may not be registered with a PA 300 of theE1—scans the QR code from a mobile device, the payer is directed to thewebpage or app location specified by the QR code and unique to thatpayee. If the payer is registered and logged in, the Payment PresenterPP 326 will retrieve the payer's stored payment sources and the payee'sprofile; if the payer is unknown, then he or she is simply shown themerchant's page, and the payer can pay by entering a credit/debit cardor with the device supported payment system such as Apple Pay or GooglePay. FIG. 17 depicts screenshots from E1 and shows the payment requestfrom a street performer as it is shown to an unknown payer (1702) and alogged-in payer (1704).

How does Embodiment E1 work? Shown below is the JSON representation ofthe payment request PR created by E1's Payer Agent PA 300 for the streetperformer.

  {″header″: {   ″request_id″: 4014605071,   ″merchant_id″: ″StreetComedian Joe″,   ″fulfillment_count″: ″unlimited″}  {″body″: {″ack″:″You made my day!″} }

Notice that, besides the payee's identity, this payment request has verylittle. With no amount requested and no designated payer, this requestcan be captured by anyone. Note that the PR specifies that the“fulfillment count” is ‘unlimited’. This means that PR will staypersistent in PR 314 so that any number of payers can fulfill the samePR. However, each payment will create a new Payment Transaction RecordPTR that references the same PR For each new PTR, the MA 302 will simplycredit the payee's account with the amount in the PTR but leave thestatus field of PR as ‘active’ because the “fulfillment_count” is‘unlimited.’

Although very simple, this scenario illustrates one of the advantages ofthis invention. The street performer is able to accept electronicpayment from an unknown passerby without possessing or operating anypayment infrastructure and without interrupting his performance. Beingpayer-centric, once the performer sets up the payment request, paymentsare initiated and orchestrated by the payer with no overhead for thepayee. Note that there is nothing special about the QR code itself—it issimply an easier-to-read version of the payee's URL.

E0 and E1 Combined An Infrastructure-Less, Payer-Centric Cash Register

Embodiment E0 illustrated how a merchant can create a payment requestfor a specific amount directed to a specific payer. Embodiment E1illustrated a payer identifying a merchant by their ID to make apayment. A trivial combination of E0 and E1 can be used as a simple cashregister where a merchant can create a payment request as in E0 butwithout knowing the payer's ID and a payer can scan the (static) QR codeof the merchant to retrieve the merchant's most recent payment request.Scenario 1804 (FIG. 18) shows a vendor displaying a QR code on a sheetof paper that simply identifies the merchant as in E1. The merchantcreates a payment request for a specific amount as in E0, but with nopayer ID. When a payer scans the merchant's QR code—a static ID—thepayer agent retrieves and displays the most recent payment request bythat merchant (the typical scenario for a cash register), thereby usinga static merchant ID as a proxy for a dynamic payment request. FIG. 19depicts the process flow.

This is another example of how payer-centric payments are advantageousto both customers and merchants. In the scenario described, a smallmerchant is able to transmit a payment request for a specific amount andaccept an electronic payment from an anonymous payer without needing anypayment infrastructure; the customer is able to pay a fly-by-nightstreet vendor electronically without revealing his or her identity orpayment credentials.

Embodiment E2 Paying at a Restaurant, Tips Included

Embodiment E2 supports restaurant payments: a scenario in which thepayment amount is known, the payer's identity may not be known, and thepayer may modify the payment request by adding a tip. Assume that ourrestaurant has integrated its cash register with Merchant Agent MA 302through the latter's API interface 806 so that when a check is rung up,the cash register automatically generates a payment request PR which isplaced in E2's PB 312. Now the restaurant can print the check with a QRcode that identifies the PR In FIG. 20, 2002 shows the restaurant's MA302; 2004 shows the printed check for our customer Angela.

To pay, Angela scans her check with her app 404 of E2 and her app 404retrieves the PR from PB 312. PP 326 that serves her app 404 retrievesher stored cards from her profile; it also retrieves the restaurant'slogo from Topaz Café's profile and notes that tips are applicable to itspayment requests (see FIG. 10). Based on all this data, PP 326 generatesa visual representation 2102 (FIG. 21) of the PR. When Angela adds atip, chooses a card, and authorizes the payment, PA 300 completes thepayment process depicted in FIG. 16A. PP 326 of Angela's PA 300 nowconfirms the payment, and—as instructed by the Topaz Café's profile (seeFIG. 10)—prompts Angela to review the restaurant and accept coupons asshown in 2104.

This embodiment is an illustration of a much more flexible paymentscenario where the customer does not just fulfill a payment request asgiven but modifies it by adding a tip from her own device. Note thatAngela's identity and payment credentials were not shared with therestaurant, she did not have to wait for a waiter to swipe a card andbring her an invoice for her to add tips and the restaurant did not needany payment infrastructure such as card readers.

Embodiment E3 Paying for an Online Purchase

Imagine our customer Angela visiting a fictitious eCommerce website,kids-casuals.com, adding several items to her shopping cart and checkingout. FIG. 22 is a screenshot of Angela's shopping cart. Imagine thatkids-casuals.com accepts E3.com as one of its payment options. Insteadof entering her credit card number and shipping address, Angela cancheck out by entering her E3.com ID and by ticking the box that allowsE3.com to provide her shipping address to the website. When Angelachecks out, the website creates a PR via E3's Merchant Agent'sAPI-endpoint 806. The JSON representation of the PR 2302 is shown inFIG. 23. E3's MA 302 deposits the PR into E3's PB 312 which delivers itto Angela's Payer Agent PA 300 and Angela's PA 300 displays it on hermobile app 404. Angela would pay this payment request from her mobileapp 404 much the same way she would pay any other merchant.

Practitioners familiar with the state of the art might see somefunctional similarities between our invention and other commerciallyavailable systems like PayPal. Our invention as well as PayPal hide thepayment source from the payee. However, the similarities end there.Structurally and architecturally, as a payment system, PayPal isanalogous to a computer whereas our invention is analogous to theInternet. First, the former creates a proverbial “walled garden” andrequires both the merchant and the payer to be inside the walled gardenas its clients. Second, when a payer initiates a payment from aneCommerce website, the eCommerce website invokes PayPal for the customerto authorize the payment. At that point, the only glue that holds theeCommerce website, the customer's website session and the PayPal sessionare transient website cookies. As such, all these actions have to takeplace on the same device and within the same browser almostsynchronously (or within a cookie timeout period).

In contrast, our invention externalizes a payment request with a uniqueID as a persistent, first-class object through its payment bus. And thetechnical architecture of our invention enables multiple merchant agentsand payment agents that can post and retrieve payment messages fromanywhere on the Internet. This means that a merchant can create apayment request from one device through MA 302; the request can eitherbe sent to the payer (via the payer's ID) or retrieved by the payer (viathe payment request ID) from another device through Payer Agent PA 300.As such, our invention creates what might be seen as an Internet forpayments where merchants, payers and payment requests can be uniquelyaddressed, where many merchant agents and payer agents can coexist,where any payer can pay any merchant through the payment bus withoutrequiring both parties to be inside a proprietary walled garden. CompareFIG. 25—a schematic of PayPal—with FIG. 02, a schematic of ourinvention.

Embodiment E4 Claiming a Payment from a Website, Vending Machine orRetail Store

In embodiment E4, we focus on several payment scenarios that becomepossible when a payment request is externalized so that the payer canpay by claiming the request. FIG. 24 is a screenshot of Angela'sshopping cart from E3 but adapted for E4. Unlike in E3 where Angela hadto enter her ID to receive the payment request, E4 shares the ID of theshopping cart with the customer. Much like in E3, the merchant's websitecreates a payment request PR via E4's API-endpoint 806. FIG. 23 (2304)shows the JSON representation of the PR. Note that the PR's request id(“KC-22847”) is the same as the shopping cart ID that E4 shared withAngela in FIG. 24. E4's MA 302 deposits the PR into E4's payment bus PB312. However, unlike with E3, this PR is not directed to any payer (thecustomer_id is null), so the PB 312 simply saves it in the paymentrepository PR 314 but has no payer to forward it to.

How does Angela pay? FIG. 26 shows screens 2602 and 2604 of E4's paymentapp 404. Since the merchant has shared Angela's shopping cart ID, shecan simply enter or scan the cart ID through 2602 and have her PayerAgent PA 300 retrieve it and present it to her with the PaymentPresenter PP 326 as in 2604. As noted earlier, the merchant can provideinput to PP 326 on how to present a payment request to a customer. InFIG. 07, we presented different architectures for how PP 326 and themerchant could interact. Embodiment E4's PR 2304 (FIG. 23) specifies anAPI endpoint for PP 326 for getting merchant input for presenting thisPR to the customer. PP 326 uses the architecture shown in 704 to obtainthe content and formatting instructions for Angela's cart by callingthis API endpoint (with the cart_id as a parameter). It is as ifAngela's cart has jumped off the merchant's webpage into Angela's mobileapp 404. In this scenario, the eCommerce site and the cart could be onone device (say, a PC) and Angela could retrieve the cart on anotherdevice and pay for it without involving the merchant at all.

E4 caters to a very general scenario where a payer claims a paymentrequest and pays for it in any manner the payer chooses. We nowillustrate how E4 caters to other scenarios. Imagine a vending machinethat enables customers to select multiple items and then pay with acard. Much like the payment machinery at a store, such vending machinesneed a card reader and a wide-area data connection to contact a paymentgateway. With our invention, a vending machine can eliminate the cardreader and act more like a website where the customer's snack selectionis tantamount to a shopping cart that can be claimed and paid for from amobile device as in E4.

FIG. 27 shows a conventional vending machine 2702 with a built-in cardreader 2704. It also shows a modified version 2712 where the card readerhas been replaced by a display 2714 and/or a cheap LED counter 2716and/or a contactless NFC output device 2718. When the customer has madeher snack selection, instead of expecting a payment through a cardreader 2704, the modified machine 2712 does exactly what the eCommercewebsite did in embodiment E4. The machine creates a payment request PRfor the customer's snack selection via E4's Merchant Agent'sAPI-endpoint 806 and provides the ID of the payment request as a QR codeon the display 2714, and/or as a character string on the LED counter2716 and/or as an electronic signal that can be picked up by acustomer's mobile device from the NFC output device 2718. This enablesthe customer to claim the payment request with her app 404 and pay fromthe app (as in FIG. 26). When the customer pays, the customer's paymenttransaction record is deposited by the customer's PA 300 into PB 312which routes it to the vending machine's MA 302. After MA 302 verifiesthe payment, it informs the vending machine, which dispenses the snacks.

Consider a retail scenario shown in FIG. 18. At present, stores usemerchant-centric payments: once a sale is rung up, the payer would swipeher card through a card reader 1824, an input device that reads thecustomer's credentials to complete the transaction through the store'spayment infrastructure. With E4, the store would replace the card readerwith an output device, a display 1834. When a sale is rung up, much likethe website or the vending machine, the store's cash register creates apayment request PR and provides its ID as a QR code or NFC output on thedisplay 1834. The customer scans this code and pays from her own app404.

The above scenarios show the flexibility of our invention. When apayment transaction is externalized, it is no longer coupled to atransient internal record belonging to a cash register, vending machineor an eCommerce database, but is turned into a first-class object with aunique ID that can be accessed and fulfilled from anywhere through anypayment service. E4 shows that a customer-centric payment system is moreconvenient and secure for the customer and is also cheaper for themerchant. For example, a vending machine operator no longer needs a cardreader and the security related to taking payments through unattendedmachines in remote places.

Embodiment E5 An Automated Ticket Kiosk

Imagine a bus company that operates buses between two cities. FIG. 30shows the bus company's ticket vending kiosk which is just a poster atthe bus station. When a customer scans the poster, E5 will vendindividually verifiable tickets for a given trip. FIG. 33 shows apictorial representation of the ticket vending process.

In FIG. 10, we showed how merchants can choose various parameterspertaining to their business, including the payment model. One of thepayment models they can specify is “tickets for events”. Our buscompany, Pegasus, registers as a ticket vendor and creates a paymentrequest for tickets with its Merchant Agent MA 302 and generates aposter with a QR code identifying the payment request. FIG. 30 shows theposter and 3102 of FIG. 31 shows the JSON representation of Pegasus'spayment request. This request specifies that a customer can buy multipletickets up to a maximum of 6 per customer, up to a maximum of 62 ticketsuntil 11:40 am on the specified day. Further, the bus company requeststickets be issued in PDF417 code—the code typically used for tickets andboarding passes—with a unique ID for each ticket. It also provides animage for a human identifiable stub.

To buy a ticket, a customer scans the QR code from the company's poster(3302). In response, the customer's Payer Agent PA 300 retrieves thepayment request, recognizes that the request is for a ticket, verifiesthat the number of tickets that have been fulfilled thus far is lessthan the maximum specified (3304), and sends the payment request to thePayment Presenter PP 326. 3104 of FIG. 31 shows PP 326's rendition ofPegasus' payment request. The customer can pay as described in earlierembodiments (3306). When the customer pays, PA 300 performs threeactions: (a) it increments the number of tickets fulfilled, (b) itgenerates random serial numbers for the tickets (3310), creates a PTR(3308) and attaches the ticket numbers to the body of the PTR and sendsit to the Payment Bus PB 312, and (c) passes the serial numbers to thePayment Presenter 326 which generates the tickets in the PDF417 formatrequested by the merchant (3312). See 3202 (FIG. 32) for a screenshotfrom E5 where the payer is provided two tickets in both human-readableand PDF417 format with unique serial numbers. If the number of soldtickets has not reached the specified maximum in the payment request, E5retains the payment request in Payment Repository PR 314 so E5 cancontinue to vend more tickets.

How can Pegasus validate the tickets? Since the ticket numbers wereattached to the body of the corresponding PTRs (3310), Pegasus hasaccess to the ticket numbers. 3204 (FIG. 32) is a screenshot of Pegasus'ticket validation app. When a customer presents a ticket, this app scansthe ticket (3314) for its serial number; it then looks for an associatedPTR that has the said serial number in its body (3316); if so, theticket is verified to be genuine (3318).

Embodiment E5 underscores several advantages of our invention. First, byco-opting customers' devices for payment, the merchant has completelyeliminated the need for a ticket vending infrastructure. Second, themerchant now has an elastic ticketing infrastructure whose capacityexpands to accommodate as many payers who want to purchase tickets sothere isn't a last-minute rush at one or two ticket vending machines orticket counters. Third, payers did not have to visit yet another websiteand share payment information with the merchant, but simply go to theirpayment app which not only vends the ticket, but also stores the ticketand receipt with the payer's account rather than send them to the payervia another channel like email. Finally, this scenario also indicatesthat our invention can cater not just to a payment transaction but caninvoke follow-up actions triggered by the completion of a payment.

In summary, this invention describes a system and method for electronicpayments centered on a payment bus that provides an open, looselycoupled and federated infrastructure in which merchants can requestpayment from any customer and any customer can pay any merchant throughany payment gateway. This results in lower costs for merchants andbetter security and privacy for customers. The many embodiments of thisinvention catering to widely differing payment scenarios attest to thegenerality, usefulness, and originality of this invention.

GLOSSARY

Active payment request A payment request whose status is “active.” Sameas pending payment request. API Application Programming Interface. APIsenable computer programs to interact and exchange data with each other.API endpoint A named or addressable API that has a specific purpose.Automatic payment Used interchangeably, a more accurate term forrecurring payments: multiple and/or periodic payments against a paymentsource based on a one-time authorization by the payer. Customer Same aspayer. HTTP POST One of the methods of the HTTP protocol used to submitdata to a web server. JSON JavaScript Object Notation: A datainterchange standard from European Computer Manufacturer's Association(ECMA). The standard is also known as ECMA-404. Merchant Same as payee.NFC Near Field Communications is a technology for very-short distancewireless, typically used in contactless payments. Payee Same asmerchant. Payer Same as customer. Payment credential A credit cardnumber, bank account number etc. along with information such asexpiration date, a CVC code or any other data needed to authorize apayment using that payment source. Payment message Same as paymentrecord. Payment request Abbreviated PR, a request for a payment,typically sent by a merchant to a payer. Payment Transaction AbbreviatedPTR, a record typically created by a payer or payer Record agent toconfirm a payment in response to a payment request. PCPS or PCPS Refersto any embodiment of this invention and stands for Payer- embodimentCentric Payment System. Payment Gateway A third-party service thatclears card and back transactions with financial institutions, transfersmoney, and confirms a transaction. PR Without any other qualification,PR stands for payment request. References to Payment Repository arealways qualified as PR 314. PR 314 Payment Repository 314. PTR Same asPayment Transaction Record. QR code Quick Response code, also called2-dimensional bar code. QR codes can be used to transmit up to 4K ofdata visually. Resolved payment A payment request that is no longeractive either because it has request been paid, withdrawn, past itsexpiry date or any other reason. Session cookie Same as website cookie,but the term is often used to refer to a cookie that tracks a specificuser's browsing session. .tld Tld stands for top-level domain and is acommon convention used to represent some random domain, as in p1.tld.Webhook A website URL that accepts a POST request in the HTTP or HTTPSprotocol. Webhooks are typically used to inform a web server of an eventand/or pass data to a web server. Website cookie Cookies are codes thata website stores inside a user's browser and enable a website to keeptrack of the state of a browser session.

1. A federated architecture for facilitating electronic payment forcommercial and/or financial transactions between merchants and payers,the federated architecture comprising: a network address spaceconfigured such that: merchants, payers, and payment records created bymerchants and payers in the process of completing electronic paymentsall have unique public identities (ID) by which they can be identifiedby each other; a computer-readable payment repository that stores thesaid payment records; and a payment bus comprising one or morenon-transitory computer-readable media tangibly storing computer programinstructions, wherein the instructions, when executed by one or moreonline processors, cause the one or more online processors to perform apayment bus process comprising: receiving from a merchant, via anauthenticated network connection, a payment request for a commercialand/or financial transaction involving the merchant, wherein the paymentrequest specifies the merchant as the payee of the payment request, andin response: storing the payment request in the payment repository; andsending the payment request, via an authenticated network connection, toany payer specified in the payment request; and receiving from a payer,via an authenticated network connection, a payment transaction recordcomprising the unique ID of the payment request and a paymentconfirmation, wherein the payment confirmation confirms a payment by thepayer in favor of the merchant who is specified as the payee of thepayment request, and in response: storing the payment transaction recordin the payment repository; and sending the payment transaction record,via an authenticated network connection, to the merchant specified asthe payee of the payment request.
 2. The federated architecture of claim1, wherein the payment bus process further comprises: receiving from amerchant or a payer, via an authenticated network connection, aretrieval request for a payment record in the payment repository,wherein the retrieval request specifies the unique ID of the paymentrecord, and in response: retrieving the payment record with thespecified unique ID from the payment repository; and sending, via theauthenticated network connection, the retrieved payment record to thesender of the retrieval request.
 3. The federated architecture of claim1, wherein the payment bus process further comprises: receiving from apayer, via an authenticated network connection, a retrieval request fora payment record in the payment repository, wherein the retrievalrequest specifies the unique ID of a merchant, and in response:retrieving the most recent payment request that specifies the merchantwith the said unique ID as the payee of the payment request; andsending, via the authenticated network connection, the retrieved paymentrequest to the payer.
 4. The federated architecture of claim 1, wherein,to request payment from a payer for a commercial and/or financialtransaction with the payer, the merchant performs a billing methodcomprising: creating a payment request for the transaction; sending thepayment request to the payment bus via an authenticated networkconnection; establishing, through a transfer of identifying informationbetween the payer and the merchant, an association between the payer andthe unique ID of the payment request; receiving from the payment bus,via an authenticated network connection, a payment transaction recordthat comprises the ID of the payment request and a payment confirmationthat confirms a payment by the payer in favor of the merchant; andmodifying the payment request to indicate that the payment request hasbeen paid.
 5. The federated architecture of claim 4, wherein thetransfer of identifying information between the payer and the merchantcomprises: the payer communicating information that identifies thepayer; and the merchant capturing the information communicated by thepayer.
 6. The federated architecture of claim 4, wherein the transfer ofidentifying information between the payer and the merchant comprises:the merchant communicating information that identifies the merchant orthe payment request or both; and the payer capturing the informationcommunicated by the merchant.
 7. The federated architecture of claim 1,wherein, to pay a payment request from a merchant for a commercialand/or financial transaction between the merchant and a payer, the payerperforms a payment method comprising: establishing, through a transferof identifying information between the payer and the merchant, anassociation between the payer and the unique ID of the payment request;receiving a payment request from the payment bus via an authenticatednetwork connection; sending a payment directive to an online paymentgateway, wherein the directive causes the gateway to make a payment tothe payee of the payment request using a payer-specified paymentcredential; receiving, from the payment gateway, a payment confirmationthat the payment to the payee has been successfully completed; creatinga payment transaction record that includes the unique ID of the paymentrequest and the payment confirmation received from the payment gateway;and sending the payment transaction record to the payment bus via anauthenticated network connection.
 8. The federated architecture of claim7, wherein the payer performs at least a part of the payment method froma personal mobile device.
 9. The federated architecture of claim 7further comprising: sending a retrieval request to the payment bus viaan authenticated network connection, wherein the retrieval request isbased, at least partly, on the content of the identifying informationtransferred by the merchant to the payer.
 10. The federated architectureof claim 1, wherein the address space has a hierarchical structure. 11.The federated architecture of claim 1, wherein the payment transactionrecord specifies a payment amount that includes a tip amount.
 12. Thefederated architecture of claim 1, wherein the merchant comprises anentity selected from the group consisting of an individual, a physicalstore, an online store, a vending machine, a kiosk, an institution, andany commercial outfit.
 13. The federated architecture of claim 1,wherein the merchant is represented by a computer-implemented merchantagent that performs one or more actions on behalf of the merchant andthe payer is represented by a computer-implemented payer agent thatperforms one or more actions on behalf of the payer.
 14. The federatedarchitecture of claim 13, wherein the payment bus functionssubstantially as only the repository if all merchants are represented bythe same merchant agent and all payers are represented by the same payeragent.
 15. The federated architecture of claim 1, wherein the merchantincludes any designated agent of the merchant and the payer includes anydesignated agent of the payer.
 16. The federated architecture of claim 1further comprising: upon the merchant receiving a payment transactionrecord that confirms a payment by a payer to the merchant, the merchantexecutes at least one predetermined action in favor of the payer. 17.The federated architecture of claim 16, wherein the at least onepredetermined action executed by the merchant comprises an actionselected from the group consisting of: modifying the status of thepayment request, generating a receipt, printing a receipt, emailing areceipt, issuing a ticket, generating one or more coupons, sending acommand to a vending machine, and activating a device.
 18. The federatedarchitecture of claim 1, wherein the payment record includes additionalinformation for sharing between the merchant and the payer.
 19. Afederated method for electronic payment for commercial and/or financialtransactions between merchants and payers, the federated methodcomprising: a payment bus process having authenticated networkconnection to: a network address space configured such that: merchants,payers, and payment records created by merchants and payers in theprocess of completing electronic payments all have unique publicidentities (ID) by which they can be identified by each other; acomputer-readable payment repository that stores the said paymentrecords; and wherein the payment bus process comprises: receiving from amerchant, via an authenticated network connection, a payment request fora commercial and/or financial transaction involving the merchant,wherein the payment request specifies the merchant as the payee of thepayment request, and in response: storing the payment request in thepayment repository; and sending the payment request, via anauthenticated network connection, to any payer specified in the paymentrequest; and receiving from a payer, via an authenticated networkconnection, a payment transaction record comprising the unique ID of thepayment request and a payment confirmation, wherein the paymentconfirmation confirms a payment by the payer in favor of the merchantwho is specified as the payee of the payment request, and in response:storing the payment transaction record in the payment repository; andsending the payment transaction record, via an authenticated networkconnection, to the merchant specified as the payee of the paymentrequest.
 20. The federated method of claim 19, wherein the merchant isrepresented by a computer-implemented merchant agent that performs oneor more actions on behalf of the merchant and the payer is representedby a computer-implemented payer agent that performs one or more actionson behalf of the payer.
 21. The federated method of claim 19, whereinthe merchant includes any designated agent of the merchant and the payerincludes any designated agent of the payer.